1. Field
Internet payments are usually required for vendors to grant user access to some content on the Internet.
2. Prior Art
Commerce on the Internet includes the sale of physical and digital products and services. The total amount to be paid for a single commerce operation is composed of many smaller costs, such as the cost of shipping, the cost of a payment transaction, plus some other costs. The term “payment transaction” includes the act of paying, when the money is transferred from a user to a vendor, usually with the help of a broker such as a bank or a credit card company. This money transfer usually costs something for the broker to perform, and that is called the cost of the payment transaction.
When selling physical products, such as books or CDs, it is necessary for the vendor to ship them to the buyer. The cost of shipping usually sets a minimum cost for the whole commerce operation, so that the total amount that the buyer must pay will never get very small. As a result, the cost of the payment transaction itself becomes negligible in comparison, and is not a critical factor.
However, the selling of digital products or services, such as digital music or videos, can, in most cases, be completely fulfilled through the Internet, without any shipping costs. In this case, the total amount that the buyer must pay may be indeed very small, and the cost of the payment transaction is not negligible. As an example, it may be acceptable for a vendor to spend 10 cents to complete a 15-dollar sale, but it is unacceptable to spend 10 cents to complete a 15-cent sale. When we realize that some content in the Internet may be sold for as little as one cent, or even less, it becomes apparent that transaction costs must be kept very small.
These very small payments are usually called micropayments. So, a suitable micropayment system must somehow minimize the transaction costs to make them economic for low value transactions. To minimize transaction costs, we must minimize the communication, processing, and data storage requirements placed on each part involved in the commerce operation, usually users, brokers, and vendors. In more detail, transaction costs are usually highly dependent upon the quantity of bytes of information to be sent and received by each party, upon the number of separate communication requests for each transaction, and upon the computational cost of processing the transaction, including time-consuming cryptographic and database operations.
A suitable micropayment system should also prevent fraud and minimize security risks, such as credit liability, credit abuse, counterfeiting, unauthorized withdrawal, purchase-order modification, double spending, failure to credit payment and failure of repudiation, among others. However, the goals of “minimizing transaction costs” and “preventing fraud” are sometimes contradictory because the more verification the vendor and the broker must do for a single payment transaction, the more expensive it becomes.
One of the most important fraud prevention requirements is that the system should guarantee that a user can only access some content after he or she has paid the exact amount the vendor asked for it (or after it is guaranteed that the user will pay). But, due to the way the Internet works, when a vendor includes payment information on a Web page, and this page is sent to the user's browser, it cannot be guaranteed that the user will not modify the HTML of the page (or other internal codes that result in modifying the payment information itself) before initiating payment. Therefore, when a payment occurs, the vendor or the broker must somehow determine if conditions, such as the price of the content, were not modified. A regular technique to do this is to compare the paid price to a list with prices of all the content for sale to make sure that the paid price matches the listed price.
The main disadvantage of this technique is that the price list must be consulted during the payment process to make sure the price and other conditions were not modified. This takes time and computational resources. And if the user has paid to access some content for a specific period of time, or for a specific number of times, then the vendor must keep track of the access rights of the user in order to know whether the user may still access the content without paying again. In this case, the price list may have to be verified over and over. This leads to more database operations and probably more communication overhead.
To minimize transaction costs, “off-line” payment methods have been proposed. Off-line methods do not require the participation of a broker (a trusted party) for every transaction, and usually only guarantee that fraud is detected when the vendor submit its transaction records to the broker, possibly at the end of the day. This is to be contrasted with “on-line” payment methods, which require the participation of a broker in every transaction and are secure against many types of fraud. Note that some texts refer to “on-line payments” as a synonym of “payments through the Internet”, but this is not what we mean here when referring to on-line methods. Hybrid (partly off-line) methods also exist. But, for an off-line or hybrid method, it is usually more difficult to prevent fraud, and in fact most off-line systems proposed are not even designed to eliminate fraud, but rather only to maintain it below some defined threshold.
Very little has been done in recent years to improve on-line methods for making micropayments. A review of patents and scientific articles indicates that most of the research effort in the micropayment area has been directed to developing off-line or hybrid payment methods. For example, some methods are related to electronic elements associated with monetary value or units of credit, for instance, by using technologies like the so-called hash chains, or hash collisions (not discussed in this text; see Wikipedia: en.wikipedia.org/wiki/Hash_chain and en.wikipedia.org/wiki/Hash_collision), and strive to optimize probabilistic schemes. So, there is much less prior-art for on-line payment schemes where a broker is contacted in real-time and guarantees every transaction. As already pointed out, since on-line methods present fewer fraud risks, why is most of the recent research effort directed to improving off-line methods? A common argument states that on-line payment methods cannot be made more efficient than they are in the present state of the art, and, as a consequence, that resorting to off-line methods is the only way to further minimize transaction costs. For example, Mandadi, Ravi Kumar, (2006), in “Comparison of Current On-line Payment Technologies”, Master thesis—Division of Information Theory—www.diva-portal.org/diva/getDocument?urn_nbn_se_liu_diva-7383-1_fulltext.pdf, page 45, states that “a number of payment systems, which need to contact a trusted third party during every payment have been proposed as micro on-line payment systems, but they are infeasible to handle large number of micro on-line payments as they need to contact the trusted party repeatedly”. However, I believe this argument is wrong, and that the halt in studies for on-line micropayment methods should be lifted since the development of on-line payment systems with very low transaction costs would completely obsolete off-line methods.
When ascertaining which prior payment methods are pertinent, we first note that prior payment methods cover very different aspects of the problem. For example, some methods are about issuing, transmitting, accounting, or otherwise using electronic elements associated with monetary value or units of credit, which are exchanged, transmitted, or processed, to complete the payment operation. These elements can be called tokens, digital money, digital cash, electronic coins, electronic stamps, verifiers, e-coupons, sticks of currency, scrips of currency, electronic checks, or other. Some methods are about probabilistic pooling, so that payment information need not be checked for each transaction, while reducing security risks. Other methods are about details of creating electronic wallets or purses, or hardware (like smart cards or other intelligent devices), as to better store and exchange payment information. Others disclose the specifics of dealing with prepaid stored-value cards or stored-value accounts. Other methods are about reducing credit card commissions charged by credit card providers. Some methods are about direct use of credit cards without the need to send a credit card number to a vendor. Other methods relate only to specific mobile payment issues, in cases where payment must be made through mobile phones, PDAs, or other such devices. Some methods are about deciding if a payment is either a regular payment or a micropayment, and then suggest different ways of dealing with them. Others disclose ways to debit the user from his or her telephone account. Some relate to payments made only from ATM terminals, vending machines, or other hardware. Others disclose details of digital rights management (DRM) solutions. Others rely on creating spending limits for users. Others disclose new cryptographic techniques like hash functions or digital signatures. Some methods are about details of accounting systems, or ways for charging an Internet service provider or other service provider for the purchases made by its users. Others disclose methods for establishing centralized stores for selling content of other vendors. Some are concerned with techniques for implementing one-click purchases. Other relate to methods for issuing payments automatically based on user preferences, or methods for automating post-payment necessities, such as repudiation of payments by user-initiated complaints, so as to reduce the need of a call-center. The list goes on.
All of the previous listed aspects are important and can be used in particular payment systems, but prior-arts that discuss only these aspects are not relevant here since they do not define how payment information and information flow should be construed, organized or arranged, as to perform payment in efficient ways that are specially suited to on-line micropayment systems.
We will not however, exclude prior methods just because they are directed at normal valued payments (macro payments), instead of at micropayments. They are relevant because there is no inherent transaction cost limit that separates a method from being directed to micropayments or macro payments. Simply, when methods get more efficient, they can be used with smaller prices. For example, the PayPal payment system doesn't permit economical transactions of one cent and is not very efficient, but their market is mainly directed to normal-valued payments, which are less demanding. Most payment companies, online banks, and financial institutions use very similar on-line payment schemes that are not suited to micropayments.
In the text below, we will discuss some payment methods disclosed in real-world systems and also in patents. Each system uses different words to designate the same entities, but we will facilitate the comparison by converting them to the same consistent terminology, using the following capitalized words: User, Vendor, Broker, Payment Information, Price List, Confirmation, Authorization, and content. For brief definitions of these terms, see the Introduction of the Detailed Description.
One of the main disadvantages of the prior-art payment methods is the necessity for the Vendor (or for the Broker) to check a Price List of the content for sale during the payment process. In some payment systems, this Price List (or price catalog, or price table, or price database, or any other suitable name) resides on a Vendor's computer server, while in some others it resides on a Broker's computer server. This Price List is usually in the format of a data structure or database table, but can be in other formats. This Price List can be a collection of Payment Information of content or products for sale, or can be a collection of cryptographic hashes or some other derivatives of the Payment Information. Usually this Price List contains not only price information, but also conditions such as the duration of time that the User is allowed to access the content, and many other. The reason why this Price List must exist in these prior-art methods is that the Vendor or the Broker (when trusted by the Vendor) must verify that the prices and other conditions are met.
Prior-art payment methods present other disadvantages, and each one presents a different set of disadvantages. Some of these disadvantages will be briefly pointed out for each method. Note that, in the text below, when a payment method requires more communication between parts, i.e., whether there is a larger number of independent communications, whether there is more information to be sent (in bytes), then this is a disadvantage because of increased communication and processing burdens, resulting in increased transaction costs.
Consider a simple hypothetical payment method: A User has an account with a Broker. A Vendor maintains a Price List of the content it has for sale. The Vendor provides Payment Information to the User. The User initiates payment by sending to the Broker the Payment Information and a User's identification. The Broker discounts the User and sends back an Authorization. The User sends the Authorization to the Vendor and requests the content. The Vendor communicates with the Broker to ask if the Authorization is valid. The Broker confirms that the Authorization is valid. The Vendor checks the information in the Authorization against the Price List to check if the price and other conditions are correct. If so, the Vendor may grant access to the content to the User.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) the Broker has to receive the details of the Payment Information; (iii) when the User wants to access the content again during the Authorization's validity, the User has to contact the Broker again to get another Authorization, each time; and (iv) the Vendor has to communicate with the Broker to ask if the Authorization is valid.
Very similar to the simple method presented above are payment systems called Minitix, Wallie and Way2 Pay (see Robert Parhonyi, 2005, “Micro Payment Gateways”, CTIT Ph.D.—thesis series no. 05-72, ISSN 1381-3617, ISBN 90-365-2239-0, The Netherlands, pages 264-269). In these systems, a User has an account with a Broker. A Vendor maintains a Price List of the content it has for sale. The Vendor provides Payment Information to the User. The User initiates payment by sending to the Broker the Payment Information and the User's identification. The Broker discounts the User, and then sends a Confirmation to the User and an Authorization to Vendor. The User contacts the Vendor and requests the content. The User may also send to the Vendor part of the Confirmation, or some User's identification, so that the Vendor can associate the User with the Authorization received from Broker. Then, the Vendor verifies the information of Authorization against the Price List to check if the price and other conditions are correct. If all is correct, the Vendor may grant access to the content to the User.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) the Broker has to receive the details of the Payment Information; (iii) when the User wants to access the content again during the Authorization's validity, the User may contact the Vendor directly, but the Vendor has to maintain a database of all the still valid Authorizations received from the Broker; and (iv) the Broker has to communicate with both the User and the Vendor, to send a Confirmation to the User, and an Authorization to the Vendor.
PayPal (see PayPal Company, 2006, “Order Management Integration Guide”, USA, Chapter 3—Instant Payment Notification—pages 29 to 34, www.paypal.com/en_US/pdf/PP_OrderManagement_IntegrationGuide.pdf) and a payment system called Paynova (see “Micro Payment Gateways”, already cited, in pages 272-273) also have payment methods are similar to the Minitix system. But, the PayPal system needs one more communication step between the Broker and the Vendor when the connection between them is not secure: the Vendor must send back to the Broker the Authorization it just received, so that the Broker can check to make sure it was not modified and to confirm the Authorization to the Vendor. The Paynova system also needs one more communication step between the Broker and the Vendor because when the User initiates payment by requesting Payment Information from the Vendor, the Vendor sends the Payment Information both to the User and to the Broker. Thus, when the User contacts the Broker, there is no need for the User to again send the Payment Information to the Broker.
Disadvantages of these methods are the same as in the Minitix system explained above, except for the added disadvantage of the extra communication step.
PaySafeCard (see “Micro Payment Gateways”, already cited, in pages 270-271) has a payment system in which a User has an account with a Broker. The Vendor maintains a Price List of the content it has for sale. When the User initiates payment by requesting Payment Information from the Vendor, the Vendor sends Payment Information both to the User and to the Broker, so that when the User contacts the Broker, there is no need for the User to send again the Payment Information to the Broker. Then the Broker discounts the User and sends back an Authorization. When the User requests the content from the Vendor, the Vendor communicates with the Broker to ask if the User is authorized. The Broker confirms that the User is authorized, and the Vendor verifies the information of Authorization against the Price List to check if the price and other conditions are correct. If all is correct, the Vendor contacts again the Broker to ask it to execute the debit. Then the Vendor may grant access to the content to the User.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) the Vendor needs to send Payment Information both to the User and to the Broker, as to initiate payment; (iii) the Vendor must contact the Broker directly to check if the User has really paid; and (iv) the Vendor must contact the Broker once again to ask it to execute the debit.
U.S. Pat. No. 6,058,381 (Nelson, “Many-to-many payments system for network content materials”, May 2, 2000) is an improvement over the methods presented above since it discloses a method that dispenses with the Vendor having to communicate directly with the Broker to receive an Authorization or to ask if the Authorization is valid. In this method a User has an account with a Broker. The Vendor maintains a Price List of the content it has for sale. A Vendor provides Payment Information to the User. The User initiates payment by sending to the Broker the Payment Information and the User's identification. The Broker discounts the User, digitally signs this information, generating an Authorization, and then sends the Authorization to the User. The User sends the Authorization to the Vendor and requests the content. The Vendor verifies the authenticity of the Authorization by verifying the Broker's signature. Then the Vendor verifies the information of Authorization against the Price List to check if the price and other conditions are correct. If all is correct, the Vendor may grant access to the content to the User.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) the Broker has to receive the details of the Payment Information; and (iii) when the User wants to access the content again during the Authorization's validity, the User has to contact the Broker again to get another Authorization, each time.
Very similar is a payment system called BitPass, now discontinued (see “Micro Payment Gateways”, already cited, in pages 274-275). In this system, a User has an account with a Broker. A Vendor creates, in the Broker's computer server, a Price List of the content it wants to sell. The Vendor provides Payment Information to the User. The User initiates payment by sending the Broker the Payment Information and the User's identification. Then the Broker verifies the Payment Information against the Price List to check if the price and other conditions are correct. If the Payment Information is correct, the Broker discounts the User, digitally signs this information, generating an Authorization, and then sends the Authorization to the User. The User sends the Authorization to the Vendor and requests the content. The Vendor verifies the authenticity of the Authorization by verifying the Broker's signature. If all is correct, the Vendor may grant access to the content to the User. The main difference between this method and Nelson is that here the Broker verifies the Price List, instead of the Vendor.
Some disadvantages of this method are: (i) the Broker must maintain and check a Price List; (ii) the Broker has to receive the details of the Payment Information; and (iii) when the User wants to access the content again during the Authorization's validity, the User has to contact the Broker again to get another Authorization, each time.
U.S. Pat. No. 6,029,150 (Kravitz, “Payment and transactions in electronic commerce system”, Feb. 22, 2000) adds another improvement since it discloses a method in which the Broker does not have to receive all of the details of the Payment Information. In this method a User has an account with a Broker and shares a secret key with it. The Vendor maintains a Price List of the content it has for sale. The Vendor provides Payment Information to the User, authenticated in a way that only the User can verify. The User initiates payment by sending to the Broker the Payment Information and the User's identification. The Payment Information may be cryptographically hashed so that the Broker doesn't need to receive all the payment details. The Broker discounts the User, digitally signs this information, generating an Authorization, and then sends the Authorization to the User. The User sends the Authorization to the Vendor and requests the content. The Vendor verifies the Authorization by verifying the Broker's signature and also by verifying the cryptographic hash of the Payment Information of the Authorization against the Price List. This is done to check if the price and other conditions are correct. If all is correct, the Vendor may grant access to the content to the User.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) there is the need for the User to share a secret key with the Broker; (iii) the Vendor must authenticate Payment Information specifically for each User; and (iv) all Parts must maintain databases.
Some disadvantages of this method are: (i) the Vendor must maintain and check a Price List; (ii) the Broker has to receive the details of the Payment Information; (iii) all the Vendor's content must pass through the Broker's computer servers, which not only imposes a huge communications burden for the Broker, but also is not secure for private data since anyone with free access to the Broker's system may read all the information the User receives; and (iv) when the User wants to access the content again during the Authorization's validity, the User has to contact the Broker again, and all the content must be delivered by the Broker itself, again.